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System and method for converging circuit switched and packed 
switched communications 

This invention generally relates a system and method for con- 
5 verging circuit switch and packet switched networks, and more 
particularly, to transparently route traffic from or to a 
time division multiplexed (TDM) network across a network. 

A technological shift is occurring in the telecommunications 
10 industry. Parallel to traditional circuit-switched networks 
such as time division multiplexing (TDM) networks that were 
at one time designed for voice communications, packet 
switched networks are advancing. This advancement is compel- 
ling the telecommunication industry to upgrade to newer net- 
15 works using packet networks, such as for example, Internet 
Protocol (IP) and Asynchronous Transfer Mode (ATM) . Because 
of this convergence , packet service providers like Internet 
Service Providers (ISP) may now offer value-added services 
that were once impossible to provide with circuit switched 
20 networks. The packet network information structure enables, 
amongst others, the ISPs to deliver voice and fax services 
over low cost IP backbones. 

A common goal of telecommunication companies (TELCOs) is to 
25 deploy voice-enabled data networks . Next-Generation Networks 
(NGN) deploy voice-enabled data networks offering the intel- 
ligence and reliability of circuit-switched networks with the 
speed and economy of packet-switched networks. The packet- 
switched networks must therefore economically support both 
30 existing voice services like Class 4/5 features and evolving 
applications such as integrated access, Virtual Private Net- 
work (VPN) , Internet call waiting, click to dial, unified 
messaging, enhanced roaming, or the like. 

35 There are at least two known ways to converge existing TDM 
networks into packet-networks : 
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- using a soft switch which introduces a new network 
node in the applied network, or 

using an integrated packet trunk in a Class 4/5 
switch, which is not a generic solution. 

5 

Each of the above ways has disadvantages. A soft switch re- 
quires the creation of a new node in the network. That is, a 
database change must be made making the network aware of its 
presence. This may be burdensome and costly. Further, the va- 
10 riety of functions available in the soft switch may cause 

cost and performance inefficiencies for such a narrow usage, 
when the soft switch is used for virtual trunking only. Addi- 
tionally, a soft switch causes huge database changes in the 
applied network. 

15 

The disadvantages of an integrated packet trunk in a Class 
4/5 switch include internetworking with other vendor's packet 
solutions which may not be standardized. Also the solution is. 
switch specific; that is, each vendor has to develop their 
20 own integrated packet card. 

What is needed is a generic solution for integrating TDM net- 
works and packet based networks so that the integrating of 
the two networks is seamless and does not impose significant 
25 new requirements on either the existing TDM network, signal- 
ing number seven (SS7) network, integrated services digital 
network (ISDN) or the packet network. The solution should 
also be vendor independent so that the solution may work with 
all existing manufacturer's equipment. 

3X) 

In an aspect of the invention, a system is provided for con- 
verging networks . The system comprises at least one resource 
manager (RM) which provides routing information from a net- 
work node to a signal transfer point (STP) in a network and 
35 establishes a bearer path over a packet network. 
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In another aspect of the invention, a system for routing is 
provided- The system comprises at least one resource manager 
(RM) that monitors Integrated Services Digital Network User 
Part (ISUP) messages from at least one network node for rout- 
5 ing information and rerouting a call across a packet network 
when the routing information corresponds to a known packet 
destination. 

In another aspect of the invention , a method for converging 
networks, comprising the steps of providing routing informa- 
tion from a network node to a signal transfer point (STP) in 
a network by at least one resource manager (RM) and estab- 
lishing a bearer path over a packet network based on the 
routing information . 

In another aspect of the invention, a computer program prod- 
uct is provided. The computer program product comprises a 
computer usable medium having readable program code embodied 
in the medium. The computer program product also includes at 
least one component to provide routing information from a 
network node to a signaling transfer point (STP) in a network 
by at least one resource manager (RM) and to establish a 
bearer path over a packet network based on the routing infor- 
mation . 

Embodiments of the invention will now be described with ref- 
erence to the detailed drawings, wherein: 

Fig. 1 is an embodiment of the invention for detecting and 
30 routing traffic from and/or to a TDM network across a packet- 
based network, according to the invention; 

Fig. 2 is a swim lane diagram showing the steps of an embodi- 
ment of messaging between the components of a TDM network and 
a packet-switched network, according to the invention; 
35 Fig. 3 is a block diagram of an illustrative embodiment of 
redundant CRM arrangement, according to the invention; 
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Fig. 4 is a functional block diagram of an embodiment: showing 
detecting and routing traffic from and/or to a TDM network, 
across a packet-based network, from and/or to a soft switch, 
according to the invention; 
5 Fig. 5 is a swim lane diagram showing the steps of an embodi- 
ment of messaging between the components of a TDM network, a 
packet switched network, and a soft switch, according to the 
invention; 

Fig. 6 is a swim lane diagram showing the steps of an embodi- 
10 ment of messaging between the components of a TDM network, a 
packet switched network, and a soft switch, according to the 
invention; 

Fig. 7 is a functional block diagram of an embodiment showing 
a system and method of self learning routes, according to the 
15 invention; 

Fig. 8 is a functional block diagram of an embodiment showing 
a system and method of flattening a network, according to the 
invention; 

Fig. 9 is functional block diagram of a system and method 
20 showing management of unbalanced circuit identification codes 
(CICs) , according to the invention; 

Fig. 10A and 10B are flow charts showing embodiments of using 
the invention; and 

Fig. 11 is a flowchart of an embodiment showing steps of us- 
25 ing the invention. 

The present invention is directed to a system and method for 
converging circuit switched (e.g., TDM network) and packet 
switched communications systems, for example. The system and 

30 method provides for dynamically detecting when a call placed 
from and/or to a time division multiplexing (TDM) network may 
be re-routed to and across a packet switched network. The 
system and method of the invention further allows for more 
efficient and cost effective communications, and may be used 

35 to monitor and regulate data across the TDM and packet 

switched networks. In embodiments, the invention dynamically 
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learns and stores which calls may be suitable for re-routing 
over the packet network, instead of the circuit switched net- 
work, thereby avoiding the necessity of pre-building a rout- 
ing database. 

5 

Fig. 1 is an embodiment of the invention for detecting and 
routing traffic from and/or to a TDM network across a packet- 
based network, generally denoted as reference 100. The inven- 
tion includes a convergence resource manager (CRM) 105a, 105b 

10 inserted between an end office 110a, 110b and signal transfer 
points (STPs) 115a, 115b, respectively. The end office 110a, 
110b is typically a Class 5 TDM switch (but may be other 
classes of switches). The CRM (e.g., 105a or 105b) may indi- 
vidually interface with the one or more TDM end offices and 

15 interact with the one or more TDM end offices independently. 
That is, one CRM may monitor and process activity for more 
than one end office. The CRM 105a, 105b typically interfaces 
with routing databases 107a, 107b, respectively, and contains 
pre-conf igured routing information to map dialed numbers to 

20 end point destinations and routes. The CRM 105a, 105b may 

also include information as to whether any particular dialed 
destination may be reachable via the packet network and 
hence, eligible for re-routing over the packet network in 
lieu of the TDM network. In embodiments, the databases 107a, 

25 107b may be a part of the CRM 105a, 105b. 

The CRM 105a, 105b also sniffs (i.e., monitors) all entering 
and exiting ISDN User Part (ISUP) messages. In one aspect of 
the invention, the CRM 105a, 105b, sniffs only in the termi- 

30 nating direction (i.e., calls routed towards the end office). 
For calls originating from the end office, the CRM 105a, 105b 
may also moderate messages over the SS7 links of that office 
in the originating direction. The CRM 105a, 105b may also in- 
terface with a packet network 130 via connection 132. In em- 

35 bodiments, the packet network 130 may represent other types 
of networks such as a wireless network. 



5 



WO 2005/013572 PCT/EP2004/051687 



The invention may also include media gateway 120a, 120b and 
associated call agent (CA) 125a, 125b, respectively, coupled 
to a packet network 130. A CA is typically part of a media 
5 gateway (in embodiments the CA may be a part of the CRM) and 
provides interfaces for services to/from the media gateway. 
In embodiments, the CA and media gateway may be one entity. 
The CA 125a, 125b additionally may provide the operational 
messaging interface to the media gateway (e.g., for control- 

10 ling the media gateway) and may require additions or updates 
to the functional interface (e.g., software dynamic link li- 
braries, software version upgrades, or similar functional up- 
date procedures) to achieve interoperability with the media 
gateway for achieving messaging and control functions, ac- 

15 cording to the invention. 

All bearer- relevant ISUP messages on SS7 links are analyzed 
by the CRM 105a, 105b for associated TDM trunks 142a, 142b 
connected to the media gateway 120a, 120b, respectively, 

20 which, in turn, is controlled by the CRM 105a, 105b, respec- 
tively. On reception of such bearer related ISUP messages, 
corresponding bearing path processes are" started or con- 
trolled. All other ISUP messages, which are neither bearer 
related, nor corresponds to the TDM trunks connected to media 

25 gateway 120a, 120b and controlled by CRM 105a, 105b, pass 
through transparently. 

It should be understood that CRM 105a, 105b does not repre- 
sent a new node in the TDM network. Therefore, the CRM 105a, 
30 105b may be a generic solution for converging a TDM network 
with a packet network without replacing any Class 4/5 
switches or adding a new node. The advantages of a CRM may 
include, but not limited to: 

35 - Glare is handled on the ISUP signaling side of the 

call (TDM switch side) . Hence, an unsuccessful alloca- 
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tion of an end point may not lead to complex glare 
considerations. 

- Minimum ISUP protocol handling; that is, the CRM needs 
5 to send only the packet call/bearer-relevant ISUP mes- 

sages so that the bearer path over packet may be es- 
tablished, modified, or released. All other ISUP mes- 
sages that do not affect the bearer path need not be 
handled. The bearer-path relevant ISUP messages may 
10 include, for example, initial address message (IAM) , 

address complete message (ACM) , answer message (ANM) , 
release message (REL) , and release complete message 
(RLC) . 



15 - Class 4/5 feature sets may be maintained without modi- 

fication, as these are transparent to the CRM. 

Enables calls originated from a Class 4/5 switch to 
terminate to the packet network or conversely enables 
20 incoming calls from the packet network to terminate to 

the Class 4/5 switch. 



25 



Indifference to any particular manufacturer of the 
packet or TDM equipment. 



To illustrate some of these advantages, by way of example, 
upon origination of a call at end office 110a, the CRM 105a 
sniffs (i.e., monitors) the SS7 ISUP messages between the TDM 
switch and the STP 115a and may recognize call associated 

30 messages and any routing information such as dialed directory 
number (DN) and/or carrier access code (CAC) . From the 
sniffed SS7 messages, the CRM 105a translates the point codes 
and circuit identification codes to IP addresses for the 
gateways at both ends (i.e., originating end and terminating 

35 end), which is accessible to the CRM. The CRM 105a then 

passes media gateway control information to the involved me- 
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dia gateway 120a to establish a bearer path. Since media 
gateway 120a is aware of its corresponding media gateway, 
i.e., 120b, the media gateway pair 120a, 120b typically can 
set up and establish a bearer- path with each other, independ- 
5 ently. This may be accomplished through commonly known IP 
routing and translation data at each media gateway. 

Fig. 2 is a swim lane diagram showing the steps of an embodi- 
ment of messaging between the components of a TDM network and 

10 a packet-switched network, according to the invention. Fig. 2 
(and all other swim-lane diagrams and flow charts) may 
equally represent a high-level block diagram of components of 
the invention implementing the steps thereof. The steps of 
Fig. 2 (and all the other swim lane diagrams and flow charts) 

15 may be implemented on computer program code in combination 

with the appropriate hardware. This computer program code may 
be stored on storage media such as a diskette, hard disk, CD- 
ROM, DVD-ROM or tape, as well as memory storage devices or 
collection of memory storage devices such as read-only memory 

20 (ROM) or random access memory (RAM) . Additionally, the com- 
puter program code may be transferred to a workstation over 
the Internet or some other type of network. 

Swim lane diagrams may show the relationship and typical mes- 
25 saging sequencing among "actors" or "components". The compo- 
nents of the swim lane diagram include an originating end of- 
fice 110a and corresponding terminating end office 110b for 
originating and terminating an exemplary call sequence. Fur- 
ther included in the swim lane diagram is CRM pair 105a, 
30 105b, the combined CA/MG 120a, 125a and corresponding com- 
bined CA/MG 120b, 125b. For ease of explanation, the STPs 
115a and 115b are illustratively shown as one component; how- 
ever, there may be any number of individual STP nodes in- 
volved to facilitate call processing through the TDM network. 

35 
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Referring to Fig. 2, an exemplary call sequence (and associ- 
ated sequenced messages among the components) is shown where, 
generally, a call is originated from an idle state 200 to a 
talk state 205 and then upon termination of the exemplary 
5 call, back to the idle state 200' . To illustrate this exem- 
plary call sequence in more detail, at step 210, the origi- 
nating end office 110a sends origination message (IAM) to- 
wards the signal transfer point 115a, in accordance with 
usual SS7 protocols, and may contain routing information such 
10 as a directory number (DN) , B-party ID, or carrier access 

code (CAC) . The originating end office (also generally known 
as the "A" side) is typically "unaware" of the presence of 
the CRM 105a and believes that it is communicating with a 
STP. 

15 

At step 215, the CRM 105a intercepts the IAM message and 
holds off the IAM message towards the STPs . Instead, the CRM 
105a sends an Act__EP_A message (or similar originating mes- 
sage, as appropriate) , to the CA/MG 120a, 125a which acti- 

20 vates the packet endpoint CA 125a to begin a packet origina- 
tion sequence. Alternatively to step 215, at step 215a, the 
CRM 105a may send a CRCX (EPID-A) message directly to the far 
end CRM 105b, if connectivity permits this operation. There- 
fore, alternative step 215a essentially by-passes step 220 

25 and continues at step 225. 

At step 220, since the originating CA 125a knows and is aware 
of the terminating CA 125b (due to commonly known and em- 
ployed packet routing data) , the CA/MG 120a, 125a pair is 

30 able to communicate via the packet network with CA/MG 120b, 

125b. CA 125a sends a create connection, e.g., CRCX (EPID-A), 
message which identifies the end point ID of the "A" side and 
a reference ID of the ongoing ISUP call (IAM) and correspond- 
ing circuit ID for establishing a bearer path to the far end 

35 CA/MG 120a, 125b. 
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At step 225, the CA/MG 120b, 125b at the far end, sends a 
Seize_EP_B message towards the terminating CRM 105b which in- 
cludes identification of the endpoint of the "B" side (i.e., 
end office 110b) and may indicate a channel has been seized 
5 and an ongoing call is expected on the ISUP signaling path 

for terminating the call to the end office 110b. At step 230, 
the far end CA/MG 120b, 125b sends an acknowledge create con- 
nection message (CRCX_ACK) back towards the originating end 
over the packet network and may indicate that an endpoint ID 
10 (EPID) and corresponding channel is available to the termi- 
nating end office 110b. This message typically includes the 
identity of the B-side end point (EPID-B) . 

At step 235, the originating end CA/MG 120a, 125a returns an 
15 acknowledge message (Act_EP_Ack) back to the originating CRM 
105a, indicating a packet bearer channel may be established . 
At step 240, the originating CRM 105a, which had "held off" 
the I AM message, originally sent by the originating end of- 
fice at step 210, now forwards the I AM originating message 
20 towards the STP 115a, 115b, in accordance with usual SS7 pro- 
tocols. At step 245, the originating I AM message propagates 
through the SS7 signaling network, perhaps over several STPs, 
to the terminating CRM 105b. At step 250, the terminating CRM 
105b provides the IAM message to the end office at the B-side 
25 to continue the normal SS7 protocol to the terminating end 

office 110b. A terminating sequence (e.g., ringing) may then 
begin at a far end subscriber. 

At step 252, the terminating end office 110b sends an address 
30 complete message (ACM) back towards the originating side, in 
typical SS7 fashion. At step 254, the far end CRM 105b recog- 
nizes the ACM and forwards it on to the appropriate STP 
(e.g., 115b). At step 256, the ACM is prorogated through the 
SS7 signaling network all the way back to the originating CRM 
35 105a. At step 258, the originating CRM 105a propagates the 

ACM to the originating end office 110a. At step 260, the far 
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end end office 110b may eventually send an answer message 
(ANM) when the far end subscriber answers. 

At step 2 62, the ANM may be propagated by the far end CRM 
5 105b back to the appropriate STP node (e.g., 115b) which, in 
turn, at step 2 64, may propagate the ANM all the way back to 
the originating CRM 105a. At step 266, the originating CRM 
105a returns the ANM to the originating end office 110a to 
complete the call set-up and connection. At this point, a 

10 'stable talk state (i.e., a stable connection for voice and/or 
data) is maintained signified by the horizontal bar 205. Now 
the talk path is completed through the packet network, at 
least in part. The end offices 110a, 110b are typically not 
aware of the packet bearer path as established by the inven- 

15 tion since this is transparent to the end offices 110a, 110b. 
Instead, the end offices 110a, 110b may still assume that the , 
bearer path has been created over a TDM circuit switch net- 
work . 

20 The connection is maintained in a stable talk state (or simi- 
lar connection state, as appropriate) until an end office de- 
tects a change in conditions such as a hang-up. In this exam- 
ple, the originating end office 110a detects the hang-up by a 
subscriber and forwards a release message to the CRM to ini- 

25 tiate a disconnect sequence. 

To illustrate this disconnect sequence, at step 268, end of- 
fice 110a recognizes that a subscriber has hung up and sends 
a release message (REL) towards CRM 105a. At step 270, the 
30 CRM 105a propagates the REL message toward the STP node 115a. 
At step 272, the STP node 115a REL propagates the REL to the 
far end CRM 105b. The REL may traverse multiple STP nodes, as 
necessary. At step 274, the CRM 105b passes the REL onward 
toward the far end end office 110b. 

35 
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At step 276, the CRM 105a sends (which may be nearly simulta- 
neous with step 270) a deactivate endpoint (DAct_EP_A) mes- 
sage towards the near end CA 125a for initiating the release 
of the packet connection. At step 27 8, the originating CA/MG 
5 120a, 125a forwards a delete connection message, e.g., 

DLCX(EPID-A) , towards the far end CA/MG 120b f 125b. This mes- 
sage typically includes the "A" side end point ID. 

At step 280, the far end CA/MG 120b, 125b may translate the 
DLCX(EPID-A) message and advise the far end CRM 105b of the 
connection release by a release endpoint "B" message 
(RELJEP_B) . At step 282, the CA/MG 120b, 125b acknowledges 
the release of the "B" side by sending a delete connection 
acknowledge (DLCX_ACK) message with the "B" endpoint ID 
(EPIDJB) towards the originating CA/MG 120a, 125a. At step 
284, the originating CA/MG 120a, 125a acknowledges the re- 
lease to the originating CRM 105a, completing the disconnec- 
tion sequence of the packet connection. 

At step 286, the end office 110b sends a release complete 
(RLC) message to CRM 105b. At step 288, the CRM 105b propa- 
gates the RLC message to the STP 115b. At step 290, the RLC 
message is propagated across the SS7 network to CRM 105a. At 
step 292, the CRM 105a sends the RLC message to the end of- 
fice 110a completing the disconnect sequence. 

Fig. 3 is a block diagram of an illustrative embodiment of 
redundant CRM arrangement, according to the invention. This 
embodiment is shown as a hot-standby mode; however, other 
standby modes may be implemented and are contemplated by the 
invention such as both CRM units actively handling separate 
end offices and, when necessary due to a failure, one CRM as- 
suming all the workload for both CRMs . 

Referring to Fig. 3, a pair of CRMs 105a and 105a f are shown 
with CRM 105a in an active mode and CRM 105a 1 in a standby 
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mode. The CRM 105a, 105a 1 pair may be arranged so that hard- 
ware switches 300, 305 act in tandem under control of switch 
control 340. The hardware switch 300 may be inserted between 
end office 110a via A-links 310 and the CRM 105a, 105a 1 pair. 
5 Similarly, hardware switch 305 may be inserted between the 
CRM 105a, 105a' pair and the STP 115a. 

All ISUP messages to active CRM 105a are also monitored by 
standby partner CRM 105a 1 . The active CRM 105a moderates 
10 originating ISUP messages, as denoted by reference numeral 

320 and sniffs terminating ISUP messages, as denoted by ref- 
erence numeral 325, and as described above. The standby CRM 
105a T sniffs only the ISUP messages in both directions, as 
denoted by reference numerals 330 and 335. 

15 

A heartbeat, signal between the CRM pair, denoted by reference 
numeral 345, ensures outages of the active CRM 105a is de- 
tected by its standby partner. When the heartbeat stops or 
becomes erratic, the standby CRM partner 105a' takes over ac- 

20 tive processing by switching itself to active and its partner 
105a to standby. This also causes the switching of the asso- 
ciated SS7-links, denoted by reference numeral 315, to the 
newly activated active CRM 105a 1 . This hot-standby method may 
be A-link related so that the standby CRM for a given A-link 

25 may be an active CRM for another A-link (not shown) . In em- 
bodiments, the CA 125a may be embedded as a software entity 
in a CRM. In this case, the redundancy of the CA is embedded 
in the redundancy of the CRMs . 

30 Fig. 4 is a functional block diagram of an embodiment showing 
detecting and routing traffic from and/or to a TDM network, 
across a packet-based network, from and/or to a soft switch, 
generally denoted as reference numeral 450. This embodiment 
includes a CRM 105a inserted between an end office 110a and 

35 signal transfer points 115a and 115b, respectively- Also in- 
cluded is soft switch 400 which interconnects with a SS7 net- 
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work (e.g., 115a , 115b) and one or more customer premise 
equipment (CPE) 405 which may also be in connection with the 
soft switch 400 via the packet network 130. The soft switch 
may represent a network node. The soft switch 405 may also 
5 interface with other types of customer communication devices 
such as key systems, private branch exchanges (PBXs) and/or 
analog, digital or wireless devices. 

The communications across the SS7 network may employ bearer 
10 independent call control (BICC) , as denoted by reference nu- 
meral 415. BICC is a call control protocol used between nodes 
and is based on the ISUP protocol. BICC has been adapted to 
support the ISDN services independent of the bearer technol- 
ogy and signaling message transport technology, and is an ex- 
15 ample of a protocol that may be well suited for coordinating 
the convergence of TDM and packet networks, as provided by 
the invention. A BICC message typically includes a generally 
known call instance code which reflects the individual cir- 
cuit (e.g., a circuit allocated between the end office and 
20 media gateway on a per origination/termination basis) deter- 
mined by bilateral agreement and/or in accordance with appli- 
cable predetermined rules . In this way, a call instance is 
mapped and tracked to a physical or logical circuit, as nec- 
essary. 

25 

Communication between soft switch 400 and CPE 4 05 may be via 
the packet network 130 and signaling path 420 which may in- 
clude session initiated protocol (SIP) . In embodiments, a 
bearer path 425 may be established between the CPE 405 and 
30 media gateway 120a for delivery of data and/or voice. 

The CRM 105a eliminates any need for the EO 110a to be con- 
figured with additional data such as the switch type (e.g., 
based on point code) , relation of CIC and end point IDs 
35 (EPIDs), or the like, since these are stored in the CRM 105a. 
Thus, from the EO 110a point of view, the routing database 
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pointing to the soft switch 400 node is the same database as 
if the soft switch 400 node were a TDM switch. ISUP messages 
originating from the EO 110a to the soft switch node may be 
enhanced by the CRM 105a and may be converted to ISUP:BICC 
5 messages for transmission to the soft switch. 

Likewise, CRM-relevant data emanating from the soft switch in 
the ISUP:BICC messages may be extracted and traditional ISUP 
messages sent to the EO 110a. In this manner , a CRM such as 

10 depicted by reference numeral 105a may manage a bearer path 
through the packet network by instructing the associated 
CA/MG such as 120a, 125a, accordingly. This convergence tech- 
nique may significantly ease acceptance by operating compa- 
nies since upgrades or programming may be avoided in the TDM 

15 nodes . 

Fig, 5 is a swim lane diagram showing the steps of an embodi- 
ment of messaging between the components of a TDM network, a 
packet switched network, and a soft switch, according to the 

20 invention. The components of the swim lane diagram include an 
originating end office 110a, CRM 105a, the CA/MG 120a, 125a, 
STP nodes 115a, 115b, and soft switch 400. The swim lane dia- 
gram of Fig. 5 is illustrative of an exemplary call originat- 
ing from the end office 110a and terminating at the soft 

25 switch 400. In general, the call transitions from an idle 
state 400 to a talk state 405 and back to the idle state 
400 1 . 

To illustrate this exemplary call sequence in more detail, at 
30 step 410, the originating end office 110a sends an originat- 
ing message (IAM) towards the signal transfer point 115a, in 
accordance with normal SS7 protocols. The originating end of- 
fice 110a is typically "unaware" of the presence of the CRM 
105a and believes that it is communicating with an STP. At 
35 step 415, the CRM intercepts the IAM message, determines that 
the call is eligible for re-routing across the packet network 
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(e.g., from internal pre-built digit translation tables), and 
suspends the IAM message, i.e., does not forward it to the 
STP 115a. Instead, the CRM 105a issues an activate endpoint 
<Act_EP-A) message to the CA/MG 120a, 125a which activates 
5 the packet end point CA 125a to begin a packet origination 
sequence across the packet network. 

At step 420, the CA 125a sends an Act_ EP_Ack message, includ- 
ing the end point identifier of end point A, to the CRM 105a 

10 to acknowledge the reception of the ActJEP-A message. At step 
425, the CRM 105a sends a BICC:IAM (EPID-A) message towards 
the STP 115a which includes the IAM origination message (or 
equivalent) with the "A" side end point identifier. At step 
430, the one or more STPs 115a, 115b forward the BICC message 

15 through the SS7 network to soft switch 400. 

At step 435, the soft switch sends a BICC message back to 
STPs 115a, 115b, which includes an address complete message 
(ACM) and the end point "B" identifier (EPID-B) . At step 440, 
20 the STP 115a, 115b forwards the BICC message towards the 

originating CRM 105a. At step 445, the CRM 10.5 translates the 
BICC message to a plain ISUP ACM message, as necessary, and 
sends the ACM toward the end office 110a, advising that ad- 
dressing is complete. 

25 

At step 450, the CRM 105a sends a modified end point "A" mes- 
sage (ModJEP_A) including a parameter identifying the "B" 
side end point IP address (EPID-B) . In this way, the CA 125a 
is advised of the identity of the "B" side for use by the 
30 CA/MG 120a, 125a for addressing packets to or identifying 

packets and protocols from the "B" side. At step 455, the CA 
120a acknowledges reception of the advisory with an acknowl- 
edge signal (e.g., ModJEP__Act) . 

35 At step 4 60, when a user answers, the soft switch 400 sends a 
BICC answer message (BICC : AJSfM) through the SS7 network. At 
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step 465, the STPs 115a, 115b forwards the BICC:ANM back to 
CRM 105a. At step 470 , the CRM 105a may translate the BICC 
answer message into a plain ISUP answer message <ANM) and 
sends the ANM to the end office 110a. 

5 

At step 475, when a subscriber or user at the end office 110a 
terminates the session, the end office 110a sends a release 
(REL) message towards the CRM 105a to initiate a disconnect 
sequence. At step 477, the CRM 105a translates the ISUP: REL 
10 message into a BICC: REL and sends the BICC: REL across the SS7 
network. At step 4 7 9, the STP 115a (and any number of inter- 
vening STPs/ as necessary) forwards the BICC: REL message to 
the soft switch 400 informing the "B" side to release the 
connection. 

15 

At 483, the soft switch 400 sends a release complete message 
(BICC:RLC), indicating "B" side disconnect. At step 485, the 
STPs 115a, 115b forwards the BICC:RLC to the CRM 105a. At 
step 487, the CRM 105a converts the BICC:RLC message to an 
20 ISUP RLC message and sends to the end office 110a, completing 
the disconnect sequence. 

Fig. 6 is a swim lane diagram showing the steps of an embodi- 
ment of messaging between the components of a TDM network, a 

25 packet switched network, and a soft switch, according to the 
invention. The components of the swim lane diagram include an 
originating end office 110a, CRM 105a, the CA/MG 120a, 125a, 
STP nodes 115a, 115b, and soft switch 400. The swim lane dia- 
gram of Fig. 6 is illustrative of an exemplary call originat- 

30 ing from the soft switch 400 and terminating at the EO 110a. 
In Fig. 6, the "A" side (originating side) now refers to the 
soft switch and the "B" side (terminating side) now refers to 
EO 110a. In general, the exemplary call transitions from an 
idle state 600 to a talk state 605 (or other stable connec- 

35 tion state) and back to the idle state 600'. 
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At step 610, the soft switch 400 initiates an origination 
(e.g., based on a call dialed by a subscriber) by recognizing 
the requested destination and transmitting a BICC:IAM message 
over the SS7 network towards STP 115b. The BICC message in- 
5 eludes the identification of the A end point (EPID-A) and the 
destination end point. In one aspect, this BICC message 
propagates across one or more STPs, as necessary, to the CRM 
105a associated with the "B" side, at step 615. 

10 At step 620, the CRM 110a translates the BICC:IAM message and 
forwards a typical ISUP I AM message to EO 110a with the CIC 
corresponding to the EPID-B chosen by CRM 105a. At step 625, 
the CRM 110a proceeds with advising the CA/MG 120a, 125a of 
the origination, in anticipation of establishing the bearer 

15 path over the packet network, by sending an activate end 

point "B" message (Act_EP_B) which includes the identity of 
the "A" end point (EPID-A) . This initiates the CA processes 
for managing the packet and CIC connections, as appropriate. 
Any packet startup processing such as codec selection may 

20 also be performed. At step 630, the CA/MG 120a, 125a acknowl- 
edges the activate message (Act_EP_Ack) . 

At step 635, the EO 110a sends an ACM to CRM 105a indicating 
that the addressing is complete (e.g., ringing started). When 

25 the CRM 105a has received both the ActJEP__Ack and the ACM in- 
dicating that the "B" side related components are ready to 
provide a talk/bearer connection, at step 640, the CRM 105a 
sends an address complete BICC message (BICC: ACM (EPID-B) ) 
with the identifier of endpoint "B" across the SS7 network. 

30 At step 645, the STP 115b relays the BICC message to the soft 
switch 400. 

At step 650, an ANM message is sent by the EO 110a when an 
answer event occurs, to the CRM 105a. The CRM 105a translates 
35 the ACM message to a BICC: ANM and sends the message across 

the SS7 network. At step 655, STP 115b relays the BICC: ACM to 
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the soft switch 400 indicating that an answer has occurred. 
At this time, a stable connection is maintained, e.g., talk 
state 605. 

5 At step 660, when the EO 110a detects a disconnect (e.g., 

hang-up) from a subscriber, a REL message may be sent in nor- 
mal ISUP fashion; although the EO 110a may believe that the 
message is being sent to a STP. At step 665, the REL message 
may be intercepted by the CRM 105a, translated to a BICC:REL 
message and sent over the SS7 network. At step 670, the STP 
115b forwards the BICC:REL message to the soft switch 4 00. 

At step 675 , which may be simultaneous with step 665, the CRM 
105a sends a deactivate end point message (DAct_EP-A) to the 
CA/MG 120a, 125a to idle the packet bearer channel and asso- 
ciated processes. Any resources, e.g., codecs, assigned to 
the call may also be released. At step 680, a DAct_EP_Ack 
message acknowledging the deactivate end point message may be 
sent to the CRM 105a. At step 682, the soft switch completes 
the disconnect sequence by sending a BICC:RLC message, indi- 
cating a release complete, over the SS7 network. At step 684, 
the one or more STPs 115a, 115b propagate the BICC:RLC to CRM 
105a. At step 688, the CRM 105a translates the BICC:RLC to a 
ISUP RLC message and sends the ISUP RLC to the EO 110a, re- 
turning call assets to an idle state. 

Fig. 7 is a functional block diagram of an embodiment showing 
a system and method of self learning routes, according to the 
invention, generally denoted by reference numeral 700. The 
system and method 7 00 also describes the steps of the inven- 
tion, as indicated by steps SI - S18, as described more fully 
below. The system and method 700 include network nodes 701a- 
701f, typically TDM nodes with subscriber devices 702a-702b, 
and associated SS7 network 715. The subscriber devices 702a- 
702b may be any type of communications device such as a 
phone, a computer, a PBX system, FAX, a key system, or the 
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like. The embodiment of Fig. 7 is illustrative and the place- 
ment of the SLSs may be essentially anywhere in the network, 
as appropriate . 

5 Also included are media gateways (GW) 705a-705d, each inter- 
connected with an associated network node 701a-701f and IP 
packet network 720 or other types of networks such as a wire- 
less network, for example. Each GW 705a-705d may also include 
a CA, as previously describe. The SLS system and process 700 

10 also includes Self Learning Switches (SLS) 710a-710d / each 
interconnected with a MG 705a-705d, and each SLS 710a-710d 
inserted between a network node (e.g., 701a, 701b, 7 Old and 
701f) and a corresponding STP (e.g., 718a, 718b, 718d 
and718f ) . The network nodes 701a-701f and GW 705a-705d are 

15 interconnected with an appropriate amount of TDM trunks 750 
for the traffic expected between each interconnected pair of 
network nodes. That is, the TDM trunking capacity may vary 
from one pair of network nodes to another pair of network 
nodes, based on capacity requirements. 

20 

In general, the functions of an SLS include the functions of 
the previously described CRM; however, an SLS is also capable 
of dynamically learning routing patterns as traffic origi- 
nates and is processed, as describe more fully below. Because 

25 a SLS is now capable of building and populating its own rout- 
ing database 711, operating personnel are not required to 
pre-conf igure a routing database which substantially avoids 
tedious and onerous database configuration procedures that 
typically occur when a new network device is added to a net- 

30 work. As a result, converging TDM networks and packet net- 
works becomes easier and a much more attractive process. 

The steps of the using the system and method 700 may assume 
that no routing data has been initially created in the SLS 
35 710a-d or database 711. Therefore, calls are placed over the 
TDM trunks 750 (at least initially) may use the TDM network 



20 



WO 2005/013572 



PCT/EP2004/051687 



and not the packet network (or other network such as a wire- 
less network) . Once routing has been learned and a database 
constructed, then calls may be routed over the packet network 
or other types of networks such as wireless, as described be- 
5 low. 

By way of example, at step SI, a subscriber device 702a 
originates a call (e.g., dials a telephone number) which is 
received by the "A" side node 701a (Nl) . At step S2, Nl cre- 

10 ates an ISUPrlAM message and sends it toward associated STP 
node 718a. However, at step S3, the SLS 710a intercepts the 
ISUPrlAM message, consults a routing database and determines 
that the route for the dialed number is unknown to the SLS 
710a. At S4, the SLS 710a notifies the GW 705a to establish a 

15 one-to-one trunk connection between Nl and node 701b. At S5, 
the SLS adds a Tag 725 to the I AM message 722 which includes 
the SLS ID (e.g., IP address of SLS 710a) and, typically, a 
call reference number. 

20 At step S6, the STP 718a routes the call to the next node 
701b; ISUPrlAM message 722 with TAG 725 traverses STP 718b 
and is monitored by the SLS 710b. At step S7, the SLS 710b 
recognizes the TAG 725 in the ISUPrlAM message 722 and reacts 
by notifying the originating SLS 710a (which is identified in 

25 the Tag 725) , and reports "Tag seen" by node 701b along with 
the ID of SLS 710b. The "Tag seen" report may be made over 
the packet network, but may also be accomplished via any 
other suitable connection such as a wireless network or the 
SS7 network. The "Tag seen" message may alternatively be 

30 propagated across the SS7 network. In embodiments, a counter 
may be maintained as part of the ISUPrlAM message which is 
incremented by each reporting SLS and also returned as part 
of the "Tag seen" report. In this manner the SLS 710a may be 
able to more easily differentiate the order of reporting SLSs 

35 and verify a total number of traversed SLSs. At step S8, the 
SLS 710b adds a second Tag 730 to the I SUP : I AM message with 
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the identity of the SLS 702b (e.g., IP address). At S9, the 
SLS 710b notifies the GW 705b to establish a one-to-one trunk 
connection between node 701b and 701c. 

5 At step S10, each TDM node (e.g., 701c), without an associ- 
ated SLS, passes the ISUPrlAM and Tag(s) transparently and 
traverses additional STPs as necessary (e.g., STPs 718c and 
718d) . At step Sll, the SLS 710c recognizes the Tagged 
ISUPrlAM message and reports "Tag seen" by node 7 Old along 
10 with its own identification to SLS 710a. At S12, the SLS 710c 
changes the second Tag 730 to a new second Tag 735 that now 
bears the identification of SLS 710c. At S13, the SLS 710c 
notifies the GW 705c to establish a one-to-one trunk connec- 
tion between node 701d and node 701e. 

15 

The ISUPrlAM message with two tags propagates along the SS7 
network (e.g., through STP 718e, node 701e and STP 718f ) , as 
necessary. It should be apparent that a node, such as nodes 
701c and 701e, may not have an associated SLS. The ISUPrlAM 

20 message with tag(s) simply propagates through these nodes 

(i.e., 701c and 701e) in typically SS7 fashion. At step S14, 
the SLS 710d recognizes the Tagged I SUP: I AM message and re- 
ports "Tag seen" along with its own ID to SLS 710a. At step 
S15, the SLS 710d modifies the second Tag 735 with its own 

25 Tag 740 and propagates the ISUPrlAM message to node 701f (N2) 
for call termination at the "B" side. At step SI 6, N2 deliv- 
ers the call and rings subscriber device 702b. At step S17, 
an answer causes a ISUP answer message ISUPrANM (alterna- 
tively, an address complete message might be used) to be 

30 propagated back through the SS7 network, where, at step SI 8, 
the "A" side SLS 710a creates a record or entry in a routing 
database associating the last reported "Tag seen" node infor- 
mation (e.g., end point identifier of N2, media gateway ad- 
dress, or SLS address) with the dialed number (or CAC) . The 

35 last reported "Tag seen" may be determined by various ways 
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such as using a pre-determined timeout for allowing re- 
sponses . 

In this way, the SLS 710a may build a routing database for 
5 dialed numbers, by matching dialed numbers with a SLS of a 
"B" side as determined by the Tag reporting scheme. Further, 
entries may be created to any reporting SLS so that routes 
may be defined to any intermediate SLS. In this way, when 
placing a call, if a primary SLS is not responding, a call 

10 may be routed to an alternate SLS so that a subset of the 
packet route may be utilized. With this information, the 
SS7/TDM network may be by-passed, at least in part and/or at 
least as far as the last reporting SLS and associated node, 
by redirecting a call across the packet network from an 

15 originating node to the node associated with the last report- 
ing SLS. This can be reflected by the self learned routing 
database associated with the originating "A" side SLS. 

Fig. 8 is a functional block diagram of an embodiment showing 
20 a system and method of flattening a network, according to the 
invention, generally denoted by reference numeral 800. The 
system of Fig. 8 is similar to the system of Fig. 7, with 
like components having the same reference numerals; however, 
the method of Fig. 8, shown by steps S51 through S60, now il- 
25 lustrate the steps of flattening a network. The database 711 
is now assumed to be built to an operable degree with routing 
information, according to the self learning method as de- 
scribed in relation to Fig. 7. The database 711 may be con- 
tinually evolving by being updated as calls are originated 
30 over time. 

At step S51, a subscriber dials a call which is recognized by 
node 701a (Nl) . At step S52, Nl sends an ISUP:IAM message to- 
wards its STP. At step S53, the SLS 710a monitors the 
35 ISUP:IAM message and recognizes that the dialed sequence has 
a valid routing entry available in database 711, i.e., the 
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route for packet routing is known. At step S54, a call ini- 
tialization sequence may occur between SLS 710a and SLS 710d. 
Alternatively,, if the primary SLS (i.e., SLS710d) is non- 
responsive, an alternate SLS (e.g., 710c) may be selected 
5 based on database 711. At step S55, the "B" side SLS 710d re- 
ceives the call request with information about SLS 710a, 
EPID-A, data for the bearer path set-up, and data to create 
the ISUP message 722' (IAM) toward the SLS 701f for the ongo- 
ing call- At step S56, the SLS 710d may return an acknowl- 
10 edgement message including the "B" resource ID. 

At step S57, a signaling path is established. At step S58, a 
bearer path is setup, which may typically include each SLS 
710a, 710d advising each corresponding GW 705a, 705d of the 
15 impending call along with parameters such as call reference 
number and/or which circuit that the call will be using in 
reference to each node Nl and/or N2, as appropriate. 

At step S59, the SLS 710d generates an ISUP: IAM message 722 T 
20 to N2 as if the message originated from a neighboring node, 
as node 701f would expect. At step S60, N2 delivers the call 
and rings the subscriber device. The SLS 710a and 710d may 
also recognize and process in an orderly manner any typical 
ISUP messages, such as release messages, that may be sent by 
25 Nl and/or N2 . 

The system and method 800 provides an efficient flattening of 
the TDM network by re-routing calls across the packet network 
thus avoiding much of the TDM network. The routing database 

30 711 does not require pre-conf iguration and when the routing 
database 711 has reached a usable state, as determined by 
rules or overt management decisions, calls may be flexibly 
routed either over the packet network, or over the TDM net- 
work, as appropriate. Rules may even be constructed to route 

35 a percentage of calls over one network or the other due to 

business or other reasons, such as capacity or quality level 
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considerations . The percentage may even vary based on time of 
day, time zone considerations, or implementation schedule . 

Fig. 9 is functional block diagram of a system and method 
5 showing management of unbalanced circuit identification codes 
(CICs) , according to the invention, generally denoted by ref- 
erence numeral 900. The system and method 900 includes TDM 
nodes 905a-905d (N1-N4), SLS 910a, 910b interconnected with 
Nl and N2, respectively, along with gateway 920a, 920b (GWA, 

10 GWB) interconnected with SLS 910a, 910b, respectively. GWA 

920a (which may include a CA) interconnects with Nl via trunk 
group 925 having a plurality of trunk circuits (1-n) . GWA 
920a also interconnects with node N2 905b with a trunk group 
having a plurality of trunk circuits (1-3) 930, and GWA 920a 

15 also interconnects to packet network 720 via suitable network 
interface. Likewise, a similar configuration is shown for N4 
905d, GWB 920b, SLS 910b and N3 905c. A SS7 network including 
STPs 915a and 915b is also provided interconnected in suit- 
able fashion to SLS 910a, 910b, respectively, and N2 905b and 

20 N3 905c, respectively. 

In order to manage circuit connections at a media gateway, 
certain information is necessary for the SLSs (i.e., 910a and 
910b) to have. For example, the SLS must know the ordering of 

25 the TDM circuits to the media gateway, nodes or circuits in 
the TDM network and their properties such as assigned origi- 
nating point codes (OPCs) and/or circuit assignments. This 
information may be pre-programmed or the SLS can typically 
discover this information automatically for effective control 

30 of circuits and calls during the flattening process. The SLS 
may obtain OPCs by reading signals directly on the SS7 links. 

To discover this information automatically, it is known that 
in the ISDN user part of SS7, the defined protocols typically 
35 include allocation of circuit identification codes (CICs) to 
individual circuits determined by bilateral agreement and/or 
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applicable rules with corresponding elements (e.g., two con- 
nected switches) in the SS7 network. In this manner, a cir- 
cuit is known by a common identification by each element. 
This CIC information is typically not directly available to a 
5 SLS; but, each circuit in trunk group 925 and 930 has an as- 
signed circuit identifier. By way of example, in order for 
the SLS 910a to discover the identity of these circuits in 
trunk groups 925 and 930, the SLS 910a may disturb the states 
of the circuits in trunk group 925 and 930, for example, by 

10 resetting the circuits and observing the reported CICs for 

each circuit. As the trunks and circuits reestablish back to 
normal operation, the SLS 910a observes the ISUP reset mes- 
sages (RSM) generated by corresponding nodes, i.e., Nl and 
N2, respectively, to acquire the CIC relationship of physical 

15 connections of the trunks to the media gateway 920a con- 
trolled by SLS 910a. 

Typically, trunks are mapped one-to-one with a corresponding 
node (e.g., between Nl and N2, if GWA were not present). That 

20 is, circuit one on Nl would be circuit one on N2 . However, 

this rule may now be discarded when the SLS manages the CICs 
and gateways. With the presence of the packet network 720 and 
its virtual circuits (i.e., the packet network represents a 
large number of virtual trunk circuits as represented by ref- 

25 erence numeral 935) , the effective number of connections 

available to Nl may be much more than the number of circuits 
purchased and obtained from N2 . 

Therefore, the SLS 910a may dynamically remap CIC numbering 
30 and effect cross-mapping at the gateway 920a, as necessary, 
to direct calls either to the TDM network via N2 and Nl. The 
SLS may also redirect calls to the packet network 720 via 
virtual circuits 935. By way of example, if a call arrives 
over the TDM network to N2 and then routed towards Nl on CIC 
35 number one (from N2 1 s point of view) in trunk group 930, N2 
would expect Nl to receive the call on CIC number one since 
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this is the pre-agreed relationship. However, with the GWA 
and SLS present, CIC number one (from Nl's perspective) in 
trunk group 925 (i.e., between Nl and GWA) may already be in 
use, possibly due to a previous call routed across the packet 
5 network 720. Therefore, in order to accept and route the new 
incoming call from N2, the SLS 910a may remap the incoming 
call (i.e., trunk group 930, CIC one) to a different Nl CIC, 
causing GWA to cross connect to an available circuit to Nl, 
for example, CIC twelve (in trunk group 925) . In this way, 
10 the full capacity of the trunk group 925 on Nl may be better 
utilized and possibly permit a reduction in total trunks pur- 
chased between Nl and N2 . This result is caused by calls be- 
ing routed to the typically higher capacity packet network. 

15 Fig. 10A and 10B are flow charts showing embodiments of using 
the invention. Fig. 10A begins at step 1000 and Fig. 10B 
starts at step 1050. At step 1005, an SLS may disturb the 
circuits interfacing with an associated gateway in order to 
determine CICs of trunks to and from the gateway. At step 

20 1010, the SLS monitors originating ISUP messages in order to 
determine eligibility for re-routing over a packet network. 
At step 1015, a check may be made as to whether an originat- 
ing call is eligible for re-routing. This may be accomplished 
by referring to a routing database to ascertain whether the 

25 dialed number in the originating ISUP message has a known end 
node and associated SLS. The SLS may also determine point 
codes by monitoring ISUP messages from and to monitored 
nodes. If a known end node and eligible for packet routing, 
at step 1020, the call may be established over the packet 

30 network per the routing database to the known end node and 

associated SLS, thereby flattening the TDM network, at least 
in part. 

If not known, then at step 1025, a Tag may be applied to the 
35 ISUP message by the originating SLS with parameters including 
denoting the address of the originating SLS. The amended ISUP 
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message is sent over the SS7 network in typical ISUP fashion 
to set-up the call. At step 1030, at every traversed SLS and 
associated node, the traversed SLS sends a "Tag seen" message 
to the originating SLS, per parameters in the ISUP message, 
5 and conveys the address and/or identification of the trav- 
ersed node and/or SLS . The traversed SLS may modify the ISUP 
message with the traversed SLS identification and send the 
ISUP message forward, as appropriate. 

10 At step 1035, the originating SLS receives the "Tag seen" 

message and may record the instance in a database, noting the 
sending SLS and associated node for the identified call. At 
step 1040 , based on the last received "Tag seen" message, a 
routing entry may be built in the originating SLS routing da- 

15 tabase, associating the dialed number, B-party name, or CAC 

with an end node (i.e., last reporting node location or asso- 
ciated SLS) . At step 1045, the process ends. 

Referring to Fig. 10B, at step 1055, a call disconnect may be 
20 detected by an end office and reported in typically ISUP 

fashion. An associated SLS at the end office may recognize 
the ISUP disconnect and recognize that the disconnect is as- 
sociated with an established packet connection. At stepl060, 
the SLS may direct a gateway, typically via a CA, to release 
25 the packet channel associated with the call. This may include 
notifying a "B" side SLS and gateway of the disconnect mes- 
sage. At step 1065, call resources that were used in the call 
may be idled. This may include replying to the end nodes with 
SS7 messages to complete the disconnect sequence. At step 
30 1070, the process ends. 

Fig. 11 is a flowchart of an embodiment showing steps of us- 
ing the invention, starting at step 1100. At step 1105, a CRM 
monitors ISUP messages for determining point codes and, for 
35 originating messages, recognizes a request for initiating a 
call. At step 1110, the SLS consults a routing table in a 
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routing database containing information whether a route is 
known between the CRM and an end node (and associated CRM and 
gateway) for the dialed "B" party. 

5 At step 1115, a check may be made as to whether a route is 
known. If not, then at step 1120, the call may be routed in 
usual SS7 fashion over the TDM network. If, however, a route 
is known in the routing database, then at step 1125, based on 
the routing information, the CRM causes activation of end- 

10 points at the "A" and "B" sides by messaging respective gate- 
ways (and/or associated CRM) and provides identification in- 
formation of each side, as appropriate. At step 1130, the CRM 
may send a create connection message to the "B" side to es- 
tablish a bearer channel over the packet network. At step 

15 1135, the CRM may forward an originating I AM message forward 
over the SSI network to the "B" side. At step 1140, an ad- 
dress complete message may be sent by the "B" side indicating 
that the address information has been processed. Further, an 
answer message may be sent indicating a subscriber answer has 

20 been detected. At step 1145, a packet connection is com- 
pleted. 

At step 1150, a hang-up or release may be detected by an end 
office. At step 1155, the release may be propagated through 
25 the SSI network to the other side. At step 1160, a CRM may 
react to the release message by causing deactivation of the 
end points and packet connection associated with the call. At 
step 1165, call resources may be released for the call. At 
step 1170, the process ends. 

30 

In accordance with the invention, a flexible and convenient 
way of converging a TDM network and a packet network can now 
be provided. The convergence does not require changes to the 
TDM network configuration, such as adding new point codes for 
35 example, nor does the convergence require database modifica- 
tions to the TDM routing databases. The invention is trans- 



29 



WO 2005/013572 



PCT/EP2004/051687 



parent to an existing network, and capable of efficiently 
routing data or calls over a packet network, or switching 
data or calls between the TDM network and packet network de- 
pending on certain predetermined criteria such as, for exam- 
5 pie, time of day, network traffic, available capacity, time 
zones, amongst other examples. 

While the invention has been described in terms of embodi- 
ments, those skilled in the art will recognize that the in- 
10 vention can be practiced with modifications and in the spirit 
and scope of the appended claims. 
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